Wiki

This page documents the process of the switch from the "First Last" format BibSonomy used until 2011 to store author and editor names of publications to the "Last, First" format.

ToDos

Posts aus der DB holen (über REST-API direkt von bibsonomy.org), Hashes neu berechnen und vergleichen
herausfinden, ob wir schon Posts mit inkonsistenten Hashes haben
im nächsten Schritt herausfinden, ob unsere neue Implementierung evtl. Hashes verändert
Problem könnten Imports mit falsch getrennten Autoren-Namen machen (mit Komma statt mit " and "getrennt)
JabrefModelConverter testen

REST-API

Ein- und Ausgabe stets Last, First
Problem: alte Daten aus der DB müssen umgewandelt werden
Klappt das mit den Clients? JabRef?

Clients/Plugins

Typo3?
JabRef-Layout-Rendering klappt?

Export-Formate

Welche müssen wir anpassen?
JSON?
BibTeX? - konfigurierbar?

weitere Probleme

Sicherstellen, dass Hash-Berechnung nicht kaputtgeht!
Autor-Batch-Skript anpassen

Hash-Berechnung

Hashes, die sich ändern

Bei folgendem Post ändern sich die Hashes:

   log_date: 2011-07-26 17:55:24
       date: 2010-09-07 12:03:02
change_date: 2010-09-07 12:03:02
   simhash2: badb93cbb25b8fa5bcf5923f5a5e1d5e
      title: Wirtschaftsethische Perspektiven
     author: NULL
     editor: Arnold, {Volker} and Gaertner, {Wulf}
       year: 2000
  entrytype: proceedings
    journal: NULL
  booktitle: NULL
     volume: NULL
     number: N.F., 228,5

das liegt daran, dass die Herausgeber schon falsch herum in der Datenbank stehen (mit Komma) - so wie es gar nicht sein sollte - der Hash aber ohne sie umzudrehen berechnet wurde. Bei der "neuen" Berechnung werden die Herausgeber umgedreht und dadurch ändert sich der Hash:

old normalized string = simhash2 = badb93cbb25b8fa5bcf5923f5a5e1d5e (Wirtschaftsethische Perspektiven  Arnold Volker and Gaertner Wulf 2000 proceedings    NF2285)
new normalized string = simhash2 = d7bb4c97e871be24904f5d02ecaad0f0 (Wirtschaftsethische Perspektiven  Volker Arnold and Wulf Gaertner 2000 proceedings    NF2285)

Eigentlich ist die zweite Variante die richtige, aber so haben wir das bisher halt nicht gemacht. Da anzunehmen ist, dass noch weitere einträge in der Datenbank existieren, die schon ein Komma enthalten, dürfte das häufiger passieren. Leider ist dieser Fall nicht wirklich abzufangen, d.h., wir müssten für diese Einträge die Hashes neu berechnen und in der Datenbank aktualisieren - mit allen nicht so schönen Folgen:

bibtex-Tabelle aktualisieren
bibhash-Tabelle aktualisieren
ggf. GoldStandardPost-Tabelle aktualisieren
log_bibtex so lassen?
externe Links laufen ggf. ins leere

Um mal ein Gefühl zu bekommen, wie viele Einträge das betrifft:

SELECT COUNT(*) FROM bibtex WHERE LOCATE(',', author) > 0; ----> 10121
SELECT COUNT(*) FROM bibtex WHERE LOCATE(',', editor) > 0; ----> 948

Kaputte Einträge in der Datenbank

''siehe auch vorherigen Abschnitt''

Es gibt neben Einträgen, die bereits ein Komma enthalten (s.o.) auch Einträge, die ein Semikolon enthalten:

SELECT COUNT(*) FROM bibtex WHERE LOCATE(';', author) > 0; ----> 25057
SELECT COUNT(*) FROM bibtex WHERE LOCATE(';', editor) > 0; ----> 173

Daher stellt sich generell die Frage, ob das Semikolon wie ein Komma behandelt werden sollte?

'''Achtung''': Beim Semikolon gibt es mehrere Fälle zu unterscheiden:

"David Kempe and Jon Kleinberg and \Éva Tardos"
"Kirsch KA; Schlemmer M; De Santo NG; Cirillo M; Perna A; Gunga HC"

Done

Zusammen mit dem 2.0.18 Release am 22.9.2011 wurde der SimHashCleaner angeworfen. Ergebnis:

observed posts: 2795609
changed hashes: 21015
printed hashes: 10307
updated hashes: 20215
changed person: 939
pnp exceptions: 127
loop-time in s: 1069.22

Die 127 Exceptions kommen von Personennamen in der Datenbank, die der Parser nicht parsen kann. Zusätzlich gibt es noch 800 Posts, deren Hash nicht geändert werden kann, weil der Besitzer schon einen anderen Post mit dem gleichen Intrahash haben. Dadurch kann auf diese Posts nur noch eingeschränkt zugegriffen werden. Diese Einträge kann man mittels grep "^updating post" SimHashCleaner.log| wc -l ermitteln.